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This Supplemental Appellants' Brief is submitted in 
response to a USPTO Communication dated June 3, 2005 indicating 
that the original Appellants' Brief filed February 16, 2005 was 
not in compliance with 37 CFR § 41.37, specifically 37 CFR § 
41.37(c) (1) (v) . Responsive thereto, this Supplemental 
Appellants' Brief includes a concise explanation of the subject 
matter defined in each of the independent claims on appeal 
including reference to the specification by page and line number 
and (if possible) to the drawings, by reference characters. 
Accordingly, this Supplemental Appellants' Brief is believed to 
be in compliance with 37 CFR § 41.37(c) (1) (v) . 

I . REAL PARTY IN INTEREST 

The real party in interest in the present appeal is 
Goldman, Sachs & Company, a partnership formed under the laws of 
the State of New York with its principal place of business 
located at 85 Broad Street, New York, NY 10004, USA (hereinafter 
"Assignee") , as evidenced by an assignment of the entire right, 
title and interest in and to the application from the inventors, 
Ian J. Deverill, Safe E. Hammad, Alex D. Hassan and Warren P. 
Finnerty, to Assignee, which is recorded in the USPTO at reel 
012109 and frame 0231. 

II . RELATED APPEALS AND INTERFERENCES 

There are no other appeals or interferences known to 
Appellants, Assignee or the undersigned which will directly 
affect, be directly affected by or have a bearing on the Board's 
decision in the presently pending appeal. 
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III. STATUS OF THE CLAIMS 

The status of the claims in the application is as follows: 

Claims 1-12 remain in the application and are finally 
rejected. 

IV. STATUS OF AMENDMENTS FILED SUBSEQUENT TO THE FINAL 
REJECTION 

No amendments were filed subsequent to the Final Rejection. 

V. SUMMARY OF THE CLAIMED SUBJECT MATTER 

Most broadly, the invention defined in the claims on appeal 
is addressed to methods, application program interfaces and 
systems for monitoring the performance of computer systems using 
transaction latency data. The claims on appeal include three (3) 
independent claims, claims 1, 6 and 9. 

The method of monitoring a computer application recited in 
independent claim 1 on appeal involves the steps of (with 
reference to specification page and line numbers in 
parentheses) : 

without predefining events describing the potential stages 
of a transaction to be executed by said computer application 
(contrasting the present invention with the system described in 
the first complete paragraph at page 5 of the specification) , 
adding software code to said computer application for assigning 
a single general reference to characteristic transactional 
information associated with said transaction (specification at 
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page 14, lines 8-21, page 17, line 17 through page 18, line 3, 
and page 25, second complete paragraph) ; 

using said single general reference to identify transaction 
events performed by said computer application in executing said 
transaction (specification at page 14, line 21 through page 15, 
line 15) ; and 

measuring said transactions (specification at page 15, line 
16 through page 17, line 16, and page 18, line 5 through page 
23, line 9) . 

Claims 2-5 on appeal further enlarge upon the method of 
monitoring a computer application executed on a computer system 
defined in independent claim 1 to define various features that 
are believed to be representative of preferred aspects thereof. 

The application program interface for use in monitoring a 
computer application executed on a computer system recited in 
independent claim 6 on appeal involves (with reference to 
specification page and line numbers in parentheses) : 

software code added to said computer application for 
assigning, without predefining events describing the potential 
stages of a transaction to be executed by said computer 
application (contrasting the present invention with the system 
described in the first complete paragraph at page 5 of the 
specification) , a single general reference to characteristic 
transactional information associated with a transaction to be 
executed by said computer application (specification at page 14, 
lines 13-17, page 17, line 17 through page 18, line 3, and page 
25, second complete paragraph) ; and 
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an agent for marking the time at which said software code 
is executed and tagging that time with said characteristic 
transactional information as said characteristic transactional 
information is being currently processed' by the computer' 
application (specification at page 14, lines 17-21, and page 15, 
lines 16-24) . 

Claims 7 and 8 on appeal further enlarge upon the 
application program interface for use in monitoring a computer 
application executed on a computer system defined in independent 
claim 6 to define various features that are believed to be 
representative of preferred aspects thereof. 

The computer system performance monitoring system recited 
in independent claim 9 on appeal involves (with reference to 
specification page and line numbers and drawing figure reference 
numerals in parentheses) : 

an application program interface for monitoring a computer 
application executed on a computer system (600), said 
application program interface comprising: 

software code added to said computer application for 
assigning, without predefining events describing the 
potential stages of a transaction to be executed by said 
computer application (contrasting the present invention 
with the system described in the first complete paragraph 
at page 5 of the specification) , a single general reference 
to characteristic transactional information associated with 
a transaction to be executed by said computer application 
(specification at page 14, lines 13-17, page 17, line 17 
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through page 18, line 3, and page 25, second complete 
paragraph) ; and 

an agent for marking the time at which said software 
code is executed and tagging that time with said 
characteristic transactional information as said 
characteristic transactional information is being currently 
processed by the computer application (specification at 
page 14, lines 17-21, and page 15, lines 16-24); 

an aggregator (612) for calculating computer application 
latency data from raw timing data produced by said agent 
(specification at page 26, lines 17-21);. and 

a database (610) for storing said raw computer application 
timing data and said latency data (specification at page 26, 
lines 15-23) . 

Claims 10-12 on appeal further enlarge upon the computer 
system performance monitoring system defined in independent 
claim 9 to define various features that are believed to be 
representative of preferred aspects thereof. 

The present invention employs unique methods and apparatus , 
including a novel application program interface (API), for 
measuring the precise latency of information flowing through 
computer systems regardless of system topology. The computer 
systems whose information latency may be monitored by the 
invention range from individual computers through wide area 
networks comprising thousands of computers. The metrics measured 
by the present invention include the processing time for a given 
transaction event within each computing process, the time spent 
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by the transaction between each computing process, and the time 
taken by the transaction to pass through the entire computer 
system. A "transaction event" may include a request, a response, 
a directive not requiring a response, a complete or partially 
complete subtransaction, an automatically or manually triggered 
computer function, a database store or retrieve function or any 
other time-monitorable function or calculation that may be 
performed by a computer system. 

The present invention involves the association of 
measurement or timing data with inherent transactional 
information that is ordinarily passed from one component of a 
computer system to the next in the course of executing a 
transaction by a computer application. The raw measurement or 
timing data is then used to calculate latency data for some or 
all aspects of a particular transaction. Significantly, the 
invention performs these operations based solely on references 
drawn only from the business or other transactional data 
associated with the transaction. 

According to the invention, computer systems may be 
instrumented using an uncomplicated and minimally invasive API 
that allows the execution time of every task in an application 
to be measured and transactional information to be tagged to the 
measurement or timing data. Preferably, the measurement data is 
also associated with related measurement data from other 
components or systems of the same business entity in order to 
give precise latency data and statistics for transactions that 
involve more then one segment of a business' operations. By way 
of example, a trade reference or other inherent conventional 
business information normally associated with an electronic 
business transaction may be used as the transaction identifier 
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throughout the latency measurement process. Then, individual 
tasks required for processing the task can be tagged with timing 
data whereby the data can be processed and evaluated to produce 
desired latency and/or summary data. For instance, the average, 
maximum or minimum time taken to process commodities or 
securities trades from front-office to back-office within a 
brokerage or investment house may be calculated with precision 
in order to obtain meaningful information concerning the 
efficiency of the business entity' s computerized transaction 
system. 

With the present invention, no special languages, software 
code and rules must be created to predefine and pre-classify 
events and transactions. Furthermore, no transaction handle or 
correlator needs to be created for a transaction and passed from 
one component of a computer system to the next since the 
business information normally associated with the transaction is 
itself sufficient to identify and track the transaction. Since 
no use is made of API-generated handles, the present system is 
easier to deploy in modular systems than conventional 
application response measurement (ARM) systems. 

Moreover, multiple computer systems or components that may 
be required to execute an entire transaction need not be 
confined to being client-server in nature since the API 
according to the invention can be mapped to other topologies, 
e.g., a distributed system. The technique is simple in design 
and implementation, minimally invasive, and highly scalable in 
order to accommodate potentially large volumes and frequencies 
of information flow through vast computer systems and networks. 



8 



Among its advantages, the present system eliminates guess- 
work from computer system capacity estimates, enables ready 
assessment of the performance impact of new computer application 
releases and migrations, identifies application performance 
trends, works with either intra-system or inter-system IT system 
optimization tools, assists in researching user performance 
complaints and generates system management reports. 

Presently existing computer system latency monitoring 
systems assume a wide variety of configurations and/or 
methodologies. Several of these designs were discussed at length 
in the specification of the present application as well as 
during prosecution thereof. Regardless of their individual 
constructions, indeed, because of their structural/operational 
peculiarities, none of these systems, including those disclosed 
in the references cited against the claims on appeal, is capable 
of producing the advantages afforded by the claimed invention 
now before the Board. 

As will be clearly demonstrated hereinafter, the invention 
defined in all of the claims on appeal is neither disclosed nor 
suggested, either expressly or implicitly, by the references 
relied upon by the Examiner, whether those references are 
considered individually or in any conceivably combination. 

VI . GROUNDS OF OBJECTION/REJECTION TO BE REVIEWED ON APPEAL 

A statement of each separate ground of objection or 
rejection Appellants wish to be reviewed, including the basis of 
each ground of rejection is as follows: 
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(1) The title of the invention is objected to for allegedly 
not being descriptive, i.e., is not clearly indicative of the 
invention to which the claims are directed. 

(2) Claims 1, 2, 6 and 7 stand rejected under 35 U.S.C. § 
102(e) as being anticipated by Leymann et al. (U.S. Patent No. 
6, 633, 908, "Leymann") . 

(3) Claims 3, 8 and 9 stand rejected under 35 U.S.C. § 
103(a) as being unpatentable over Leymann in view of Maccabee et 
al. (U.S. Patent No. 6,108,700, "Maccabee"), whereas claims 4, 
10 and 11 stand rejected over Leymann and Maccabee under 35 
U.S.C. § 103(a) in view of "Official Notice." 

(4) Claims 5 and 12 stand rejected under 35 U.S.C. § 
103(a) as being unpatentable over Leymann and Maccabee in view 
of "Official Notice." 

VII. ARGUMENT 

(1) Objection to the Title of the Invention 

The amended title of the invention submitted with the 
Amendment filed August 9, 2004 is objected to for allegedly not 
being descriptive, i.e., it is not clearly indicative of the 
invention to which the claims are directed. Such objection is 
respectfully traversed. 

The amended title is: SYSTEM AND METHOD TO MEASURE LATENCY 

OF TRANSACTION INFORMATION FLOWING THROUGH A COMPUTER SYSTEM. At 

Section 3, "Specification" at page 5 of the final Office Action, 

the Examiner suggested the following title: MEASURING LATENCY OF 
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TRANSACTION FLOWING THROUGH AN END-TO-END NETWORK COMPUTER 
SYSTEMS REGARDLESS OF NETWORK TOPOLOGY. The Examiner suggested a 
similar title in the first Office Action dated February 12, 
2004. Appellants respectfully decline to adopt either title 
suggested by the Examiner. 

The lengthy titles suggested by the Examiner are believed 
to be overly detailed and directed to limited instantiations of 
the present invention. For example, the first paragraph of the 
"SUMMARY OF THE INVENTION" section at page 6 of Appellants' 
specification makes it clear that the "computer systems" that 
may be monitored by the present invention may range from a 
single computer to an end-to-end network computer system. The 
Examiner's suggested titles relate only to "end-to-end network 
computer systems regardless of network topology" (emphasis 
added) . As a compromise, Appellants offered the amended title of 
the invention set forth hereinabove. Such title accurately 
captures all aspects and instantiations of the present 
invention. Accordingly, acceptance of that title is respectfully 
requested. 

(2) Rejection of Claims 1, 2, 6 

and 7 under 35 U.S.C. § 102(e) 

Claims 1, 2, 6 and 7 stand rejected under 35 U.S.C. § 
102(e) as being anticipated by Leymann et al. (U.S. Patent No. 
6,633,908, "Leymann"). Such rejection is respectfully traversed. 

For the Board's convenience, independent claims 1 and 6 on 
appeal are reproduced herebelow, with emphasis added. 
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1. A method of monitoring a computer 
application executed on a computer system, said method 
comprising the steps of: 

without predefining events describing the 
potential stages of a transaction to be executed by 
said computer application, adding software code to 
said computer application for assigning a single 
general reference to characteristic transactional 
information associated with said transaction; 

using said single general reference to identify 
transaction events performed by said computer 
application in executing said transaction; and 

measuring said transactions. 



6. An application program interface for use in 
monitoring a computer application executed on a 
computer system comprised of at least one component, 
said application program interface comprising: 

software code added to said computer application 
for assigning, without predefining events describing 
the potential stages of a transaction to be executed 
by said computer application, a single general 
reference to characteristic transactional information 
associated with a transaction to be executed by said 
computer application; and 

an agent for marking the time at which said 
software code is executed and tagging that time with 
said characteristic transactional information as said 
characteristic transactional information is being 
currently processed by the computer application. 

In the third indented subparagraph under paragraph 6 at 
page 6 of the final Office Action, the Examiner states that 
Leymann teaches "adding software code to said computer 
application (e.g., inherent, for example, addition of software 
code to the computer application when the computer application 
is created ...)•" With due deference, with regard to this 
particular feature of Appellants' claimed invention, what the 
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Examiner contends is "inherent" in Leymann is most certainly 
not. Indeed, the particular passage in Leymann relied upon by 
the Examiner to substantiate his position (as well as several 
other passages in Leymann) specifically instruct one not to add 
software to the computer application under scrutiny. 

The present invention enables the management and 
measurement of application performance in systems 

management environments without special 

instrumentation of the corresponding applications . 

The basic idea of the present invention is not to 
instrument the application components. The present 
invention contemplates instrumenting the invocation 
agent instead, which in turn is responsible for 
calling the application for execution. This solution 
provides application response measurement without any 
modification of the application being measured. As a 
consequence, no special code has to be added to newly 
or existing applications to enable them for response 
measurement . 

Leymann at col. 3, lines 5-17 (emphasis added). 



The basic idea of the present invention is to 
instrument not the application components. The present 
invention contemplates instrumenting the invocation 
agent instead, which in turn is responsible for 
calling the application for execution . 

Leymann at col. 7, line 66, through column 8, line 1 
(emphasis added) . 

The present invention relates to the area of systems 
management teaching means and a method for determining 
and managing application performance. Application 
Response Measurement (ARM) assumes that the managed 
application is a self-instrumented component. This 
requires invasive changes to existing applications or 
to add explicitly code to newly written applications. 
Due to this additional effort this will restrict the 
area of applicability of ARM. The basic idea of the 
present invention is to- instrument not the application 
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components. The present invention contemplates 
instrumenting the invocation agent instead, which in 
turn is responsible to call the application for 
execution. This solution provides application response 
measurement without any modification of the 
application being measured . It is the invocation agent 
that makes the appropriate ARM calls to furnish the 
instrumentation on behalf of the application. 

Leymann at Abstract (emphasis added) . 

Each of independent claims 1 and 6 (as well as independent 
claim 9, infra) expressly requires that software code be added 
to the computer application being monitored by the API of the 
present invention in order to assign a single general reference 
to characteristic transactional information associated with a 
computer application transaction under surveillance. In stark 
contrast, Leymann does so by way of a separate application 
invocation agent . Leymann is thus diametrically opposed in 
architecture and operation to the system and method recited in 
Appellants' independent claims 1 and 6. 

Lastly, in the "Response to Arguments" section at page 2, 
paragraph 2, of the final Office Action, the Examiner states 
(with underscoring in original text, italics added): "[I]t is 
noted that the features upon which applicant relies 'software 
code is added to the computer application being monitored by the 
API to assign a single general reference to characteristic 
transactional information associated with a computer application 
transaction under surveillance 7 are not recited in the rejected 
claim (s). Although the claims are interpreted in light of the 
specification, limitations from the specification are not read 
into the claims." 
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As plainly shown hereinabove and in the underscored 
additions to independent claims 1, 6 and 9 submitted with the 
Amendment filed August 9, 2004, the notion of adding software 
code to a computer application being monitored in order to 
assign a single general reference to characteristic 
transactional information associated with the application is 
expressly recited in Appellants' claims 1, 6 and 9 . The 
Examiner's assertion that is not is bewildering. Moreover, it is 
in irreconcilable conflict with his failed efforts to divine 
such a teaching from the Leymann patent. Query: if this 
limitation were not present in the claims presented by the 
August 9, 2004 Amendment, then why did the Examiner strive as he 
did to find it in the prior art? 

For the foregoing reasons, Appellants submit that Leymann 
fails to anticipate the present invention as claimed in 
independent claims 1 and 6 and, derivatively, their respective 
dependent claims 2 and 7. Indeed, in critical respects, Leymann 
leads one of ordinary skill in the art directly away therefrom. 
Accordingly, Appellants kindly submit that the outstanding 
rejection of claims 1, 2, 6 and 7 under 35 U.S.C. 102(e) as 
being anticipated by Leymann is improper and should be reversed. 

(3) Rejection of Claims 3, 4 and 
8-11 under 35 U.S.C. § 103(a) 

Claims 3, 8 and 9 stand rejected under 35 U.S.C. § 103(a) 
as being unpatentable over Leymann in view of Maccabee (U.S. 
Patent No. 6,108,700 "Maccabee"). Claims 4, 10 and 11 stand 
rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Leymann and Maccabee in view of "Official Notice." Such 
rejections are respectfully traversed. 
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Notwithstanding what Maccabee may or may not disclose in 
relation to Appellants' dependent claims 3, 4, 8, 10 and 11, 
Maccabee teaches directly away from independent claims 1, 6 and 
9. The disadvantages of the Maccabee system were addressed at 
length at page 5 of Appellants' specification as originally 
filed. In short, Maccabee proposes the creation of a transaction 
definition language called the ETE (End-to-End) Transaction 
Definition Language that specifies how to construct identifiable 
transactions from events and links. In an illustrated example, 
the ETE Transaction Definition Language disclosed in Maccabee 
requires the creation of twenty-one (21) lines of software code 
merely to define something as relatively simple as a Web 
commerce transaction. Merely contemplating all of the possible 
events and transactions that -might be involved in a complex 
business transaction, particularly one whose execution involves 
the coordination of several business entities and computer 
systems, is itself a daunting task. Codifying these items 
complicates the task. That is, individually defining — in 
advance — all of these possible events and transactions in 
software code in order to produce a complete set of transaction 
generation rules amounts to a potentially vast amount of 
preliminary preparatory activity that must be performed before 
the monitoring system may be placed into operation. 

The present invention requires no predef inition of events 
and thereby avoids the disadvantages of the Maccabee system. 
This beneficial feature is present in each of independent claims 
1, 6 and 9. The pertinent passage from claim 9 is 
representative : 
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software code added to said computer application for 
assigning, without predefining events describing the 
potential stages of a transaction to be executed by 
said computer application , a single general reference 
to characteristic transactional information associated 
with a transaction to be executed by said computer . 
application; 

Maccabee is therefore in direct conflict with an essential 
feature of each Appellants' independent claims 1, 6 and 9. 
Accordingly, since Maccabee leads one directly away from the 
invention prescribed in those claims, it necessary also leads 
one directly away from the invention defined by dependent claims 
3, 4, 8 10 and 11, which variously depend from independent 
claims 1, 6 and 9. As a result, since no combination of the 
teachings of Leymann and Maccabee can produce Appellants' 
invention as defined by independent claims 1, 6 and 9, no 
combination of the Leymann-Maccabee reference tandem, whether 
considered alone or in combination with "Official Notice" can 
render obvious dependent claims 3, 4, 8, 10 and 11. 

(4) Rejection of Claims 5 and 12 under 35 U.S.C. § 103(a) 

Claims 5 and 12 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Leymann and Maccabee in view of 
"Official Notice." Such rejection is respectfully traversed. 

Whether considered individually or collectively, Leymann 
and Maccabee do not suggest the novel inventions of independent 
claims 1 and 9 from which claims 5 and 12 respectively depend. 
Therefore, they do not disclose or suggest the unique method of 
monitoring a computer system or a monitoring system for doing 
same as particularly defined in Appellants' claims 5 and 12. 
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Furthermore, the Examiner has failed to show -- other than 
unsubstantiated "Official Notice" -- any tangible teaching or 
suggestion of calculating latency of transactional information 
passed between components of computer systems according to the 
formula : 

(T'i(Ucy) - T'i(Vcx)) + (T' 2 (U Cy ) " T' 2 (V Cx )) + ... + (T' m -i(U Cy ) - T' m - 
i(Vcx) ) + ( T' m (U C y) - T' m (V Cx ) ) 

m 

where : 

m = an unspecified number of transaction events, 

Ti, T 2 , T m -i, T m ; 

T'ir T f 2 , -»r T'm-i, T' m = transactional information 
pertaining to transaction events, Ti, T 2 , T m -i, 

^rru 

U Cy = start time for a transaction event at one 
component of said computer system; and 
V Cx = end time for a transaction event at another 
component of said computer system. 

Therefore, it is not lightly to be assumed that the 
asserted "Official Notice" provides sufficient basis upon which 
the Examiner may rely for specific or implied suggestion that 
the foregoing formula for calculating latency of transactional 
information passed between components of a computer system is so 
well known that "Official Notice" renders the formula generally 
known or obvious to those skilled in the art of computer 
application latency measurement. 
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Accordingly, Appellants kindly submit that the outstanding 
rejection of claims 5 and 12 under 35 U.S.C. 103(a) as being 
unpatentable over Leymann in view of Maccabee in view of 
"Official Notice" is improper and should be reversed. 

To conclude, Appellants' claims must be interpreted fairly 
and accurately. Additionally, the teachings of the prior art 
cited against the claims on appeal must be fairly and accurately 
interpreted for what they in fact disclose and/or suggest. The 
disclosures of the cited references, when so interpreted, do not 
disclose or suggest Appellants' claimed invention. Therefore, 
the invention as a whole would not have been considered 
anticipated or obvious to one skilled in this art at the time of 
Appellants' invention in light of the art relied upon by the 
Examiner. Accordingly, it is respectfully submitted that the 
Final Rejection of claims 1-12 should be reversed. 



ARCHER & GREINER, P.C. 

One Centennial Square 

Haddonfield, NJ 08033 

Tel.: (856) 354-3013 

Fax: (856) 795-0574 

e-mail : j letchf ord@archerlaw . com 



Respectfully submitted, 



Date: June 7, 2005 
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VIII. CLAIMS APPENDIX 



The claims on appeal are as follows: 

1. A method of monitoring a computer application executed 
on a computer system, said method comprising the steps of: 

without predefining events describing the potential stages 
of a transaction to be executed by said computer application, 
adding software code to said computer application for assigning 
a single general reference to characteristic transactional 
information associated with said transaction; 

using said single general reference to identify transaction 
events performed by said computer application in executing said 
transaction; and 

measuring said transactions. 

2. The method of claim 1 further comprising assigning a 
component-specific reference to said single general reference at 
each component of said computer system, said component-specific 
reference representing said characteristic transactional 
information as said computer application is executed on said 
computer system. 

3. The method of claim 1 wherein said step of measuring 
comprises measuring the processing time spent by said computer 
application at each component of said computer system and 
measuring the processing time spent by said computer application 
between each component of said computer system. 
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4. The method of claim 3 further comprising the step of 
charting latency of said computer system over a selected time 
frame . 

5. The method of claim 1 further comprising calculating 
latency of transactional' information passed between components 
of said computer system according to the formula: 

(T'i(Ucy) " T'l(Vcx)) + (T' 2 (U Cy ) - T' 2 (V Cx )) + - + (T' m -i(U Cy ) - T' m _ 
i(Vcx) ) + ( T' m (U Cy ) - T' m (V Cx ) ) 

m 

where : 

m = an unspecified number of transaction events, 

Ti, T 2 , T m _i f T m ; 
T'i, T f 2f «-f T' m -i, T' m = transactional information 
pertaining to transaction events, Ti, T 2/ T m -i, 

Tm/ 

U Cy = start time for a transaction event at one 
component of said computer system; and 
V Cx = end time for a transaction event at another 
component of said computer system. 

6. An application program interface for use in monitoring a 
computer application executed on a computer system comprised of 
at least one component, said application program interface 
comprising: 

software code added to said computer application for 
assigning, without predefining events describing the potential 
stages of a transaction to be executed by said computer 
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application, a single 
transactional information 
executed by said computer 



general reference 

associated with a 
application; and 



to characteristic 
transaction to be 



an agent for marking the time at which said software code 
is executed and tagging that time with said characteristic 
transactional information as said characteristic transactional 
information is being currently processed by the computer 
application . 

7. The application program interface of claim 6 wherein said 
software code is further operable to assign a component-specific 
reference to said single general reference at each component of 
said computer system, said component-specific reference 
representing said characteristic transactional information as 
said computer application is executed on said computer system. 

8. The application program interface of claim 6 wherein said 
agent measures the processing time spent by said computer 
application at each component of said computer system and 
measures the processing time spent by said computer application 
between each component of said computer system. 

9. A computer system performance monitoring system comprising: 

an application program interface for monitoring a computer 
application executed on a computer system, said application 
program interface comprising: 

software code added to said computer application for 
assigning, without predefining events describing the 
potential stages of a transaction to be executed by said 
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computer application, a single general reference to 
characteristic transactional information associated with a 
transaction to be executed by said computer application; 
and 



an agent for marking the time at which said software 
code is executed and tagging that time with said 
characteristic transactional information as said 
characteristic transactional information is being currently 
processed by the computer application; 

an aggregator for calculating computer application latency 
data from raw timing data produced by said agent; and 

a database for storing said raw computer application timing 
data and said latency data. 

10. The computer system performance monitoring system of claim 
9 further comprising a graphical user interface for enabling a 
user to retrieve said latency data from said database. 



11. The computer system performance monitoring system of claim 
10 wherein said graphical user interface includes means for 
charting latency of a computer system over a selected time 
frame . 



12. The computer system performance monitoring system of claim 
9 wherein said aggregator calculates latency of transactional 
information passed between components of said computer system 
according to the formula: 



23 



(T'i(Ucy) - T'i(V Cx )) + (T' 2 (U Cy ) - T' 2 (V Cx )) + - + (T' m -i(U Cy ) - T' 
i(Vcx)) + ( T' m (U Cy ) - T' n (V Cx )) 

m 

where : 

m = an unspecified number of transaction events, 

Ti, T 2/ T m _i f T m ; 

T'i/ T' 2 , »■/ T'm-i, T' m = transactional information 
pertaining to transaction events, Ti, T 2/ T m -i, 

U Cy = start time for a transaction event at one 
component of said computer system; and 
V Cx = end time for a transaction event at another 
component of said computer system. 
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